After the De-XBL project is done, most custom elements that replace XBL bindings are XUL custom elements. It would be nice to start using HTML elements so `XULElement` can be removed completely. I've started doing this with the textbox de-XBL conversions: - bug 1547372 uses HTML inputs for simple textboxes - bug 1437641 converts HTML number textboxes to <input type=number> - bug 1513343 converts XUL multiline textboxes to HTML textareas - bug 1534455 converts autocomplete textboxes to customized HTML input elements Here are a few learnings from the bugs above: * Some styling will need to be adapted to target HTML elements too * The `flex="1"` attribute doesn't work on HTML elements (they were replaced with either inline styles, or CSS in stylesheets) * There's some slight behaviour change that happened involving popups after converting XUL multiline textboxes, see bug 1546367 * From what I see, we seem to have 3 different types of elements: 1. elements with direct/almost direct HTML replacements (eg. textbox, textbox type=number, multiline textbox) 2. elements with based on HTML elements (eg. bug 1534455), those should be replaceable with customized built-in HTML elements (note: XUL buttons, while they have an HTML equivalent, the fact that they contain child markup means that they belong in the next category) 3. other elements, notably the ones involving child markup, it might be possible to use normal HTML CEs, but I haven't really tried, so I can't tell. * It's possible to simplify some elements to move them from category 3 to 2, like bug 1556561 that removes the child markup from autocomplete textboxes Haven't come across this so far, but it might be worth looking out for: * Some platform code (a11y for example) might be checking explicitly for the XUL namespace * The BaseControl/BaseText/etc. base classes, which seem tied to XUL interfaces. I think it'd be nice to get rid of them, especially BaseControl that doesn't seem to add much value.
Bug 1563415 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
After the De-XBL project is done, most custom elements that replace XBL bindings are XUL custom elements. It would be nice to start using HTML elements so `XULElement` can be removed completely. I've started doing this with the textbox de-XBL conversions: - bug 1547372 uses HTML inputs for simple textboxes - bug 1437641 converts HTML number textboxes to <input type=number> - bug 1513343 converts XUL multiline textboxes to HTML textareas - bug 1534455 converts autocomplete textboxes to customized HTML input elements Here are a few learnings from the bugs above: * Some styling will need to be adapted to target HTML elements too * The `flex="1"` attribute doesn't work on HTML elements (they were replaced with either inline styles, or CSS in stylesheets) * There's some slight behaviour change that happened involving popups after converting XUL multiline textboxes, see bug 1546367 * From what I see, we seem to have 3 different types of elements: 1. elements with direct/almost direct HTML replacements (eg. textbox, textbox type=number, multiline textbox) 2. elements with based on HTML elements (eg. bug 1534455), those should be replaceable with customized built-in HTML elements (note: XUL buttons, while they have an HTML equivalent, the fact that they contain child markup means that they belong in the next category) 3. other elements, notably the ones involving child markup, it might be possible to use normal HTML CEs, but I haven't really tried, so I can't tell. 4. some special cases like XUL trees * It's possible to simplify some elements to move them from category 3 to 2, like bug 1556561 that removes the child markup from autocomplete textboxes Haven't come across this so far, but it might be worth looking out for: * Some platform code (a11y for example) might be checking explicitly for the XUL namespace * The BaseControl/BaseText/etc. base classes, which seem tied to XUL interfaces. I think it'd be nice to get rid of them, especially BaseControl that doesn't seem to add much value.
After the De-XBL project is done, most custom elements that replace XBL bindings are XUL custom elements. It would be nice to start using HTML elements so `XULElement` can be removed completely. I've started doing this with the textbox de-XBL conversions: - bug 1547372 uses HTML inputs for simple textboxes - bug 1437641 converts HTML number textboxes to <input type=number> - bug 1513343 converts XUL multiline textboxes to HTML textareas - bug 1534455 converts autocomplete textboxes to customized HTML input elements Here are a few learnings from the bugs above: * Some styling will need to be adapted to target HTML elements too * The `flex="1"` attribute doesn't work on HTML elements (they were replaced with either inline styles, or CSS in stylesheets) * There's some slight behaviour change that happened involving popups after converting XUL multiline textboxes, see bug 1546367 * From what I see, we seem to have 4 different types of elements: 1. elements with direct/almost direct HTML replacements (eg. textbox, textbox type=number, multiline textbox) 2. elements with based on HTML elements (eg. bug 1534455), those should be replaceable with customized built-in HTML elements (note: XUL buttons, while they have an HTML equivalent, the fact that they contain child markup means that they belong in the next category) 3. other elements, notably the ones involving child markup, it might be possible to use normal HTML CEs, but I haven't really tried, so I can't tell. 4. some special cases like XUL trees * It's possible to simplify some elements to move them from category 3 to 2, like bug 1556561 that removes the child markup from autocomplete textboxes Haven't come across this so far, but it might be worth looking out for: * Some platform code (a11y for example) might be checking explicitly for the XUL namespace * The BaseControl/BaseText/etc. base classes, which seem tied to XUL interfaces. I think it'd be nice to get rid of them, especially BaseControl that doesn't seem to add much value.